A known server in a distributed system can maintain a cache of resources locally to provide independence from centralised infrastructure and/or performance benefits of avoiding network communications. Applications executing on that server make updates to the resources, generally being unaware of the existence of the local cache. If these updates are transactional, then the locks and log entries used to maintain the transactionality will also only have scope local to the server.
At some point it will be appropriate to reconcile the updates made locally with some master state held in a central server. At this point it may be discovered that the state of the updated resources has been changed since the last time the cache was reconciled. Either direct updates on the server may have taken place, or another peer distributed server may have successfully reconciled some changes to the same resources. Since the basis on which the applications made their updates to the cache are now invalid (or at least questionable) it would not be appropriate to reflect those updates in the master state.
In a replicated messaging system using optimistic locks, several applications acting on different replicas may attempt to consume the same message. These actions may be asynchronous. This will be resolved when an arbitrating server ultimately commits one of the optimistic transactions and rolls back all of the others.
U.S. Published Patent Application 2003/0149709 to Banks discloses enabling one or many replicas of a data resource to be updated independently of a master copy of the data resource, and then each replica to be separately consolidated with the master copy. If a data update is applied ‘optimistically’ to a local replica and conflicts with updates applied to the master copy (since the last consolidation with that replica), then the local update will not be applied to the master copy. All updates are treated the same and rolled back together.
Transactions in such a server fail due to contention when they try to consume or update data that no longer exists. This arises in cases where the updated data is shared between updaters—i.e. accessible to several of them. One of the reasons for failing is that one update, although not conflicting with a prior update, is dependent on a conflicting update.
A system holding a local cache may keep any records which are part of an optimistic transaction locked until the optimistic transaction is committed in the master server. This prevents any other applications running against that local cache from making changes dependent on the optimistic data. So once a cache has been updated, no more updates can be made until the optimistic transaction involving that message has been committed in the master server.